System and method for transferring data

ABSTRACT

An efficient and secure process by which users may enter sensitive information into an electronic information system. When information is required from a user, the electronic information system may be configured to generate a unique access link (uniform resource locator, or URL) for that user. The link may be sent to the user via electronic communication, such as a text message or email. When the user follows the link with a web browser, the system prompts the user to enter an additional piece of personal information that is not known to the general public. Once identity is verified, the user may be required to electronically sign agreements. The user is then prompted to enter the required information. This may allow a user to deposit sensitive information into the system without requiring the user to provide full login credentials.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority as a continuation of U.S. patentapplication Ser. No. 17/970,147, filed Oct 20, 2022, entitled “SYSTEMAND METHOD FOR TRANSFERRING DATA,” which claims priority as acontinuation of U.S. patent application Ser. No. 17/201,372, filed Mar.15, 2021, entitled “SYSTEM AND METHOD FOR TRANSFERRING DATA, SCHEDULINGAPPOINTMENTS, AND CONDUCTING CONFERENCES,” which claims priority as acontinuation-in-part of U.S. patent application Ser. No. 16/993,564,filed Aug. 14, 2020, entitled “PROCESS FOR COLLECTING ELECTRONICPROTECTED HEALTH INFORMATION WITHOUT A LOGIN,” which claims priority asa continuation of U.S. patent application Ser. No. 15/923,333, filedMar. 16, 2018, entitled “PROCESS FOR COLLECTING ELECTRONIC PROTECTEDHEALTH INFORMATION WITHOUT A LOGIN,” which claims priority to U.S.Provisional Patent Application No. 62/472,927, filed on Mar. 17, 2017,entitled “PROCESS FOR COLLECTING ELECTRONIC PROTECTED HEALTH INFORMATIONWITHOUT A LOGIN,” the entire contents of which are hereby incorporatedby reference.

BACKGROUND

The health care system needs to collect information from patients,providers, and others in order to function. This information isfrequently of a sensitive nature, so sufficient security precautionsmust be taken to safeguard the information and comply with governmentregulations. For example, such systems must comply with the requirementsof the Health Insurance Portability and Accountability Act of 1996(“HIPAA”), as well as the Health Information Technology for Economic andClinical Health Act, enacted under Title XIII of the American Recoveryand Reinvestment Act of 2009 (“HITECH”).

However, security often must be balanced against accessibility. Verysecure processes for collecting healthcare information may beinconvenient to patients or caregivers, and sufficiently onerousprocesses might be an obstacle to actually collecting healthcareinformation. Alternatively, such processes might be bypassed or workedaround if the capability exists to do so, negating much of theirsecurity value.

SUMMARY

An efficient and secure process by which users may enter sensitiveinformation into an electronic information system may be provided. Wheninformation is required from a user, the electronic information systemmay be configured to generate a unique access link (uniform resourcelocator, or URL) for that user. The link may be sent to the user viaelectronic communication, such as a text message or email. When the userfollows the link with a web browser, the system prompts the user toenter an additional piece of personal information that is not known tothe general public. (Certain examples of this additional piece ofinformation may include, for example, a video connection in which theuser's physical appearance may be verified or an audio connection inwhich a voice recognition system may verify the user's voice, oralternatively may include a medical history, a clinical assessment, asurvey, a photo, a PDF document or any other electronic document,payment information such as credit card information, or any otherinformation or agreements such as may be desired. According to someexemplary embodiments, a portion of a document or piece of information,such as a portion of a medical history or even a single line item in themedical history, or a combination of documents or pieces of information— or a combination of portions—may be used instead.) Once identity isverified, the user may be required to electronically sign agreements.The user is then prompted to enter the required information.

Such a system may, by design, permit a user to enter information withoutrequiring the user to enter a username and password. If the useraccesses the system in such a manner, without entering a username andpassword, the user may be given access in a “no-login” state.

In the “no-login” state, the user may not have access to any protectedhealth information. This means that the user may not be provided withany information by following the unique link. (However, in an exemplaryembodiment, the user may thereafter be able to provide a username andpassword, or other information, to gain access to a “login” state.)

In the “no-login” state, the user may be able to push data into thesystem. However, as discussed, the user may be “firewalled” from doinganything else. This may be analogized to a bank deposit, wherein a usermay be able to deposit funds in the bank account of another (or a bankaccount for which they have not provided appropriate credentials) butmay be firewalled from withdrawing money from the account or otherwiseaccessing its funds.

In an exemplary embodiment, such a process for collecting electronicprotected health information without a login may comply with securityrecommendations regarding two-factor authentication. Although a loginand password may not be required to deposit information, a sufficientlevel of security may be achieved because two factors are required tosubmit information: something the user has (the unique link) andsomething the user knows (personally identifying information).

In an exemplary embodiment, the system may be configured to comply withHIPAA/HITECH regulations because it does not expose protected healthinformation (PHI) of any kind. The user may opt to submit the requestedinformation, and it may be entered without requiring all of theinformation stored for the user to be exposed.

According to an exemplary embodiment, a system for providing anefficient and secure interface for transferring protected electronicinformation may be configured to perform the following steps. First, thesystem may generate and send, from a server, to a user address, a uniqueaccess link, the unique access link comprising a uniform resourcelocator (URL) directed to a transfer login page, the transfer login pagebeing a web page permitting uploading of protected electronicinformation and denying access to protected electronic information. (Inan exemplary embodiment, the user may have already created a useraccount prior to this stage.) The system may then receive a request,from a user device, to access the transfer login page, and obtain, fromthe user device, a personal identifier. This personal identifier may be,for example, a record of the user (such as, for example, a date of birthof the user), some physical attribute of the user (such as a user'spersonal photograph), or some other record such as may be desired. Thesystem may then verify the personal identifier, and, when the personalidentifier is verified, grant the user device access to the transferlogin page.

The system may also provide a full login page separate from the transferlogin page, wherein the full login page is a web page permittinguploading of protected electronic information and permitting access toprotected electronic information. At this point, the system may receivea request, from the user device, to access the full login page, andobtain, from the user device, user login credentials distinct from thepersonal identifier, such as password information. These user logincredentials may then be verified, and, when the login credentials areverified, the system may grant the user device access to the full loginpage.

In an exemplary embodiment, an access link may be provided to the fulllogin page on the transfer page. This may be, for example, a passwordentry field where the user can provide their full credentials.

In an exemplary embodiment, the system may include a secure application(such as a secure application running on a mobile device of the user)which may be used to verify the existence of one or more records orother subjects of photography. For example, according to an exemplaryembodiment, a user may need to take a photo of themselves with thesecure application, or a photo of some record. Alternatively, thepersonal identifier can be any other record or identifying informationsuch as may be desired.

In some exemplary embodiments, it may be verified that the user is onethat has consented to use the service, or it may otherwise be requestedthat the user sign one or more agreements before using the service. Insuch embodiments, an electronic signature may be collected from theuser.

In some exemplary embodiments, the system may be used to establish atleast one of a real-time audio or video connection.

In some exemplary embodiments, the system may instead be implemented ona kiosk. In such embodiments, it may be desired to have the user inputother information (such as a separate password or PIN) in lieu of havingthe user select a unique link. In an exemplary embodiment, a kiosk mayalso be used to take audio or video data, such as a photograph ifdesired. In some embodiments, an administrator may monitor the user'sactivity on the kiosk, and may be able to cut off the user's access; inother embodiments, the user's access may be terminated after a certaintime period or after the user has been inactive for some time.

BRIEF DESCRIPTION OF THE FIGURES

Advantages of embodiments of the present invention will be apparent fromthe following detailed description of the exemplary embodiments thereof,which description should be considered in conjunction with theaccompanying drawings in which like numerals indicate like elements, inwhich:

FIG. 1 is an exemplary flowchart depicting an exemplary embodiment of aprocess for collecting electronic protected health information without alogin.

FIG. 2 is an exemplary flowchart depicting an exemplary embodiment of aprocess for collecting electronic protected health information without alogin, in a “kiosk mode.”

FIG. 3 is an exemplary flowchart depicting an exemplary embodiment of aprocess for collecting electronic protected health information without alogin, in a “kiosk mode.”

FIG. 4 is an exemplary flowchart depicting an exemplary embodiment of aprocess for collecting electronic protected health information from afirst party on behalf of a second party without a login.

FIG. 5A is an exemplary scheduling interface.

FIG. 5B is an exemplary scheduling interface.

FIG. 5C is an exemplary scheduling interface.

FIG. 6A is an exemplary scheduling interface.

FIG. 6B is an exemplary scheduling interface.

FIG. 6C is an exemplary scheduling interface.

FIG. 7A is an exemplary scheduling interface.

FIG. 7B is an exemplary scheduling interface.

FIG. 7C is an exemplary scheduling interface.

FIG. 7D is an exemplary scheduling interface.

FIG. 7E is an exemplary scheduling interface.

FIG. 7F is an exemplary scheduling interface.

FIG. 8A is an exemplary scheduling interface.

FIG. 8B is an exemplary scheduling interface.

FIG. 8C is an exemplary scheduling interface.

FIG. 8D is an exemplary scheduling interface.

FIG. 8E is an exemplary scheduling interface.

FIG. 8F is an exemplary scheduling interface.

FIG. 8G is an exemplary scheduling interface.

FIG. 8H is an exemplary scheduling interface.

FIG. 8I is an exemplary scheduling interface.

FIG. 9A is an exemplary scheduling interface.

FIG. 9B is an exemplary scheduling interface.

FIG. 10A is an exemplary scheduling interface.

FIG. 10B is an exemplary scheduling interface.

FIG. 10C is an exemplary scheduling interface.

FIG. 10D is an exemplary scheduling interface.

FIG. 11A is an exemplary scheduling interface.

FIG. 11B is an exemplary scheduling interface.

FIG. 11C is an exemplary scheduling interface.

FIG. 11D is an exemplary scheduling interface.

FIG. 11E is an exemplary scheduling interface.

FIG. 11F is an exemplary scheduling interface.

FIG. 12A is an exemplary scheduling interface.

FIG. 12B is an exemplary scheduling interface.

FIG. 12C is an exemplary scheduling interface.

FIG. 12D is an exemplary scheduling interface.

FIG. 12E is an exemplary scheduling interface.

FIG. 13 is an exemplary diagram showing system architecture for aprediction system.

FIG. 14 is an exemplary diagram showing a machine learning process.

DETAILED DESCRIPTION

Aspects of the invention are disclosed in the following description andrelated drawings directed to specific embodiments of the invention.Alternate embodiments may be devised without departing from the spiritor the scope of the invention. Additionally, well-known elements ofexemplary embodiments of the invention will not be described in detailor will be omitted so as not to obscure the relevant details of theinvention. Further, to facilitate an understanding of the descriptiondiscussion of several terms used herein follows.

As used herein, the word “exemplary” means “serving as an example,instance or illustration.” The embodiments described herein are notlimiting, but rather are exemplary only. It should be understood thatthe described embodiments are not necessarily to be construed aspreferred or advantageous over other embodiments. Moreover, the terms“embodiments of the invention”, “embodiments” or “invention” do notrequire that all embodiments of the invention include the discussedfeature, advantage or mode of operation.

Further, many embodiments are described in terms of sequences of actionsto be performed by, for example, elements of a computing device. It willbe recognized that various actions described herein can be performed byspecific circuits (e.g., application specific integrated circuits(ASICs)), by program instructions being executed by one or moreprocessors, or by a combination of both. Additionally, these sequence ofactions described herein can be considered to be embodied entirelywithin any form of computer readable storage medium having storedtherein a corresponding set of computer instructions that upon executionwould cause an associated processor to perform the functionalitydescribed herein. Thus, the various aspects of the invention may beembodied in a number of different forms, all of which have beencontemplated to be within the scope of the claimed subject matter. Inaddition, for each of the embodiments described herein, thecorresponding form of any such embodiments may be described herein as,for example, “logic configured to” perform the described action.

According to an exemplary embodiment, and referring generally to theFigures, various exemplary implementations of a process for collectingelectronic protected health information without a login may bedisclosed.

Turning now to exemplary FIG. 1 , FIG. 1 displays an exemplary flowchartdepicting an exemplary embodiment of a process for collecting electronicprotected health information without a login 100.

In a first step 102, a user may establish an account, or an account mayotherwise be established for a user. According to some exemplaryembodiments, a variety of ways for an account to be established for auser may be contemplated; for example, according to some exemplaryembodiments, a staff member with certain permissions may be able to makean account for a user or may be required to create or approve an accountfor a user. In another exemplary embodiment, an account may be createdfor a user by importing it from another service or by exporting it fromthe other service to the present service; in some exemplary embodiments,a user (or other party such as a staff member with permission to importdata) may have the option to adjust certain information as necessary,such as the user's name if the user wants to use a different form oftheir name (such as a full legal name) that they were not using in theother account, or different payment information or contact information,or any other information such as may be desired. Alternatively, anaccount created for another service or for another organization may beautomatically linked to the present account without requiring an importor export step. The establishment of such an account may require theuser to enter a minimum set of personally identifiable information intothe system. This may include one or more somewhat obscure items ofpersonal information that may be used as the basis for identifying auser later on; for example, in an exemplary embodiment, a system maysolicit a user's middle name, maiden name, or date of birth for such apurpose.

According to an exemplary embodiment, the system may be designed for useby any of patients, health care providers, staff members at a healthcare facility, or outside contractors. In an exemplary embodiment, auser may be a member of any such group. In an exemplary embodiment, theuser experience provided to some groups may be different from that ofsome other groups; for example, it may be desirable to provide asomewhat higher level of security for submitting information when theuser is a healthcare professional than when the user is a patient, andas such healthcare professionals may be requested to provide multipleitems of information in order to access a no-login state. In someexemplary embodiments, the user permissions provided to a member of anyone such group may be different from the user permissions provided to amember of another such group; for example, according to some exemplaryembodiments, account creation privileges may be restricted to, forexample, certain staff members at a health care facility or certainhealth cate providers, while patients or outside contractors may stillbe able to use the system once an account has been established for them.

In a next step 104, the system may provide a unique link, such as auniform resource locator (URL) link, to a user. In an exemplaryembodiment, such a link may be provided by email, by text message, or byanother acceptable method for electronic communication, as may bedesired. In some embodiments, user may be able to customize theirelectronic communication preferences; for example, a vision-impairedpatient may request that the link be read to them in a telephone call.

According to an exemplary embodiment, a link may expire after a timeinterval. In an exemplary embodiment, this may be a predefined timeinterval, or may be a customized time interval; for example, a firstform of communication may have a first time interval associated with it,and a second form of communication may have a second time intervalassociated with it, such that a user who receives a link via email has alonger or shorter time to access the link.

In some exemplary embodiments, links may expire by other methods insteadof, or in addition to, time interval-based expiration. For example,according to an exemplary embodiment, a link may expire after it hasbeen followed a certain number of times. For example, in one exemplaryembodiment, a link may expire after it has been followed once, orfollowed a predefined number of times. In another exemplary embodiment,a link may expire after it has been followed once (or multiple times)and used successfully by the user to access a no-login state and depositinformation, and may not expire if it is followed but not usedsuccessfully by the user to access a no-login state and depositinformation (such as, for example, if the user does not complete one ormore agreements or does not deposit information). In some exemplaryembodiments, links may have one or more other security propertiesassociated with them, as may be desired. According to an exemplaryembodiment, an expiration status of a link may depend on the account orthe user privileges of the account, or may be set by an account withparticular user privileges. For example, an on-site account such as astaff account may have additional privileges (for example, it may beable to authorize the creation of accounts for patients, or may be ableto manage the importing of accounts from other organizations or performother management of accounts) and it thus may be desired to ensure thatthe account creation process for a staff member has additional security(for example, a link may expire in a very short period of time or aftera single use, after which the staff member may have to request a newlink) as compared to the account creation process for a patient (whichmay be more lenient, may allow for multiple account creation attemptsand may expire only when an account is verified as being successfullycreated). Other embodiments may also be contemplated and may beimplemented as desired.

In a next step 106, when a user has received a unique link, the user mayaccess the unique link by a properly-equipped device, which may create asecure, encrypted connection between a web browser of the user and thesystem. According to an exemplary embodiment, one or moreindustry-standard encryption standards, such as SSL or TLS, or anotherform of encryption may be used in order to secure the connection.

In a next step 108, the user may be solicited for one or more pieces ofidentifying information. In an exemplary embodiment, this piece ofinformation may be selected from the records of the user, and may be,for example, a user's date of birth. In another exemplary embodiment,the piece of information may be a piece of information specified by auser as an answer to a security question, or may be another password orpassphrase (which may permit the use of a smaller password or passphrasethan would otherwise be used, or may permit the use of a password orpassphrase that the user is not asked to regularly update).

In a next step 110, the system may optionally prompt the user with oneor more agreements that the user may be required to agree to beforeusing the system. (In other exemplary embodiments, this may not berequired, or may even be required at a different step; for example, itmay be contemplated that users may be reminded of the agreements anytime they attempt to use the system, and as a result the users may beprovided with the agreements at an early step in the process, beforethey have signed in and regardless of whether they have already signedthe agreements or not.) In an exemplary embodiment, a user may be askedto electronically sign the agreements before they are granted permissionto use the system. In an exemplary embodiment, such agreements may bepresented and archived in a manner that specifically complies withgovernment regulations, for example the federal ESIGN act.

In a next step 112, a user may be permitted to submit information in theno-login state. For example, according to an exemplary embodiment, auser may be permitted to submit one or more forms, photos, documents, orany other type of information. In another exemplary embodiment, a usermay submit photos of a driver's license or other forms of identity. Inanother exemplary embodiment, a user may submit payment information. Inanother exemplary embodiment, a user may submit health insuranceinformation, or other information that may be related to reimbursementfor care. In another exemplary embodiment, a user may submit any otherpiece of information that may be necessary to provide, facilitate,monitor, or transition care.

In an exemplary embodiment, the system may establish or may have theoption of establishing a real-time audio, video, or audio/video sessionbetween the user's system and one or more other systems. This mayoperate to connect one or more patients to one or more health careprofessionals or anyone else involved in the care delivery process.

In an exemplary embodiment, the system may include a dedicatedapplication provided to the user through which the user may be permittedor may be required to submit one or more items of information. In someexemplary embodiments, such an application may be analogous to a mobilebanking application and may offer similar capabilities. For example,according to an exemplary embodiment, a user may be required to use asmartphone application to take a photograph of the one or more forms ofidentity of the user (such as the user's driver's license) rather thanpermitting the user to upload a photograph. This may ensure that thephotos are current photos, and that the photos are not stored on thedevice and are properly encrypted when transmitted.

In an exemplary embodiment, a user may at any time be able to providecredentials in order to gain full access 114. In another embodiment, afirst system may permit the deposit of information in a “no-login”state, and a separate second system may permit the deposit and retrievalof information when a login is provided may be separate systems, whichmay function to provide additional security.

Turning now to exemplary FIG. 2 , an alternative exemplary flowchartdepicting an exemplary embodiment of a process for collecting electronicprotected health information without a login 200 may be provided. Suchan exemplary flowchart 200 may depict a “kiosk mode,” wherein a userthat is unable to access the information system from one of their owndevices (or does not wish to access the information system from one oftheir own devices) may instead access the information system through akiosk. According to an exemplary embodiment, a kiosk may be aninteractive electronic device, such as a desktop or laptop computer, atablet or mobile device, or another interactive device, as may bedesired. In some exemplary embodiments, a kiosk may be a dedicateddevice; for example, in some embodiments, a booth kiosk with a tabletdedicated to running the kiosk software may be provided. In otherexemplary embodiments, a device may be temporarily reconfigured into akiosk mode by running appropriate software. A kiosk may be provided inand maintained in a facility of a provider, which may be, for example,an office, clinic, or hospital, or may be provided in another accessiblelocation. This may facilitate information entry by patients who lackaccess to technology, ensuring that patients without such access (forexample, patients that cannot afford an appropriate device, or patientsthat were taken to a hospital without their device, or any other suchpatients) can still make use of the information system.

According to an exemplary embodiment, a user may establish an account ormay have an account established for them 202. (As noted above, accordingto some exemplary embodiments, there may be many ways in which this maybe done; for example, in some exemplary embodiments, it may becontemplated that a staff member or other authorized user may create theaccount, may be contemplated that the account information may beimported from elsewhere or exported from another service to the presentservice, may be contemplated that the account may be shared with anotherservice or otherwise created as part of a different service or on behalfof another organization, and so forth). The user may be provided with aunique identifier 204, which may be selectable by the user or may beprovided to the user, which may be done contemporaneously with (orbefore or after) the user creates their account. This may be, forexample, a PIN (such as a six-digit PIN) or may be other appropriateinformation.

A user then may access a kiosk 206 in order to deposit information. Whenthe user attempts to access the kiosk 206, the user may be prompted toenter the unique identifier and their identifying information 208; inthis way, the unique identifier may take the place of the unique linkthat would have been sent to the user had the user made use of anothersystem. The user may then be provided with agreements before using thesystem 210 (which, again, as mentioned above, may be optionally moved toa different position in the method or may be optionally removed), may beable to submit information 212, and may optionally be able to login withfull credentials 214.

Turning now to exemplary FIG. 3 , an alternative exemplary flowchartdepicting an exemplary embodiment of a process for collecting electronicprotected health information without a login 300 may be provided. Suchan exemplary flowchart 300 may depict an alternative “kiosk mode.”

According to an alternative embodiment of a “kiosk mode” 300, a user maynot be provided a unique identifier before accessing the kiosk. Instead,the user—who may specifically be a user who is a patient—may not need toenter any information. Instead, one or more administrators of the kiosk(who may be, for example, hospital staff members) may verify thepatient's identity, either personally or using a different utility. Theadministrator may then remotely trigger a device to provide access tothe kiosk.

In an exemplary embodiment, the administrator may further trigger adevice (for example, in the same operation as provision of access) tocollect audio and/or video information from the kiosk. For example, ifthe user has initiated an audio and/or video connection on the kiosk,the user's audio and/or video connection may be provided to theadministrator as well. The administrator then may be provided withremote functionality over the device so that they can monitor whetherthe user (for example, a patient) and the person that the user isconnected to (for example, a healthcare provider) are bothparticipating. In an embodiment, the administrator may be able toremotely end the session on the kiosk, for example if one or both of theuser and the healthcare provider are not participating. (Alternatively,some or all of these processes may be automatic, such that a softwareservice monitors whether the user or the other party is participating,based on attributes such as active call state information, a time periodsince either party last used the connection to make any sort ofcommunication whatsoever, and so forth, such that the software servicecan automatically terminate the connection.) In an embodiment, theadministrator may operate a dashboard that controls more than one kiosk;in an embodiment, an administrator may be able to assign device namesand control many devices simultaneously from a single dashboard.

In the process depicted in exemplary FIG. 3 , a user may have theiridentity verified 302. The user may then be granted access to a kiosk byan administrator 304, which they may then access 306. The administratormay monitor the user 308 during their session. (In some exemplaryembodiments, this may be optional, and an administrator may have theoption to monitor the user 308 during their session that they may choosenot to exercise, or the step of monitoring the user 308 may be performedby a different service such as a software service or may not beperformed at all.) The administrator may then opt to remotely end thesession 310, for example by a control dashboard. (Alternatively, thesession may be terminated 310 remotely, for example by a softwareservice that determines when the session is over, such as by listeningfor particular keywords or by waiting for a sufficiently long period ofinactivity. This may cause the session to automatically timeout orautomatically finish and end, such as may be desired. Alternatively,users may end the session, such as may be desired.)

Turning now to exemplary FIG. 4 , FIG. 4 displays an exemplary flowchartdepicting an exemplary embodiment of a process for collecting electronicprotected health information without a login 400 from a user unable toprovide the information themselves.

According to an exemplary embodiment, it may be desired to empower aguardian, such as a guardian of a person under the age of consent, aperson who is mentally incapacitated, or a person who is otherwisedisabled, to deposit information on behalf of their ward. According toan exemplary embodiment, the guardian 402 may establish an account onbehalf of the ward, or may take over an existing account (such as anaccount made by the ward before becoming physically or mentallyincapacitated). (According to an exemplary embodiment, an account mayalso be established as contemplated in previous embodiments; forexample, it may have to be created by an authorized staff member, or maybe imported from another service or shared with another organization,and so on and so forth.) The system may then provide a unique link tothe guardian 404 instead of to the ward. The guardian may then followthe link 406. The guardian may then enter some piece of informationabout the ward in order to verify the identity of the ward 408;according to an exemplary embodiment, in some cases, it may be desiredto have the guardian enter a piece of information about the guardianinstead. The guardian may then accept agreements on behalf of the ward410 (if any agreements are to be accepted; this may depend on, forexample, whether the system contemplates that any agreements need to beprovided at all, as well as whether a ward has previously signed theseagreements, and whether any new agreements need to be signed authorizingaspects peculiar to the guardianship embodiment). The guardian may thenbe able to submit information in a no-login state 412, and may be ableto provide login credentials to gain full access 414, should this bedesired.

Now referring generally to the Figures, one or more tasks may becompleted before, during, or after the execution of any of theaforementioned processes. For example, according to an exemplaryembodiment, a process may include connecting to or collecting data fromany stakeholder in the process, which may include doctors, nurses,caregivers, counselors, case managers, or any other stakeholders, as maybe desired. In an exemplary embodiment, one or more pieces ofinformation may be collected; in some embodiments, what information isrequested at any time may differ, such that each session is dynamicbased on what is being requested from that particular stakeholder at aparticular stage in the process.

In an exemplary embodiment, multiple layers of data may be collected ina single session, which may, for example, be maintained as a no-loginsession. For example, according to an exemplary embodiment, a user maysign into their account via a no-login method. The user may then beasked to sign consents and to complete one or more assessments.Following the completion of the consents and the assessments, the usermay be connected to, or may have the option to connect to, a liveaudio/video session.

Now referring to exemplary FIGS. 5-12 , an improved appointmentscheduling system and process may be provided. The system may be usedfor service providers and organizations of all types and an exemplaryembodiment described herein may be a healthcare provider embodiment.There may be multiple options for scheduling appointments of varyingtypes. More specifically, scheduling system options may include anad-hoc video scheduling, instant virtual exam room scheduling,single-page booking, or a full appointment scheduling process. One ormore scheduling options may optionally be implemented simultaneously.The scheduling systems may create and send a video connection invitationto at least one of a mobile phone number, an email address, and apatient/user signed up to the appointment scheduling system platformthrough a webpage or mobile application. The scheduling systems maycreate an audio and/or a video conferencing session and invitation forimmediate connection, a future time, or both. The scheduler and/orprovider may initiate sending an invitation from a dashboard in thescheduling system and connect immediately to the video session. In otherembodiments, the scheduler or provider may create a generic appointmenton a dashboard of the system and may join the visit from the dashboard.In still other embodiments, the scheduler and/or provider may create anappointment using a dashboard in a calendar view and may select anyprovider, location, or appointment type. The scheduler and/or providermay then join the visit from the dashboard. According to furtherembodiments, the scheduler and/or provider may use an appointmentselection triage to ensure the correct provider, location, andappointment type are chosen. The scheduler and/or provider may then jointhe visit from the dashboard. According to one or more of the schedulingsystem embodiments, the patient may receive a secure video link and jointhe visit instantly as an anonymous user; receive a secure video link(and reminders when applicable), verify identity with date of birthand/or create an account, and sign electronic consents when applicablebefore joining a visit; or receive appointment reminders, connectiontests, and a secure video link, verify identify with date of birth, andsign electronic consents and/or complete intake forms when applicable.According to an exemplary embodiment, the organization optionally maynot keep a record of the video session and may or may not track sessionmetrics.

According to an exemplary embodiment, an ad-hoc video appointmentscheduling system may be provided. The ad-hoc video scheduling systemmay provide scheduling for emergency telehealth treatment. The ad-hocsystem may also be implemented as an appointment scheduling system fororganizations that use Electronic Health Records (EHR) as a masterschedule. The ad-hoc video scheduling system may utilize appointmentinvitations sent to a mobile phone number or an email address. Ad-hocvideo scheduling may optionally set up for immediate appointments orappointments right now. Ad-hoc video scheduling may optionally allow forvideo connection scheduling only. In operation, the scheduler and/orprovider may send an invitation from a system dashboard and may connectimmediately to a video conference appointment. The user or patient mayreceive a secure video link and may join the visit using the link. Theuser or patient may join the video conference instantly upon clickingthe link. The user or patient may join as an anonymous user. In someembodiments, the anonymous user status is required when joininginstantly or when identity is not verified. According to an exemplaryembodiment, the provider organization may not keep a record of the videosession.

According to some exemplary embodiments, an ad-hoc video session mayhave restricted functionality. Ad-hoc sessions may optionally notrequire a patient account, not create an appointment record, not includefull functionality within the video session (providers may not haveaccess to patient details, appointment notes, follow-up booking, markingpatients as a no-show, etc.), not include associated reporting, and notsync with EHR.

As shown in exemplary FIG. 5A-5C, a Start Ad-Hoc Video button 502 may bepresented on an organization or provider dashboard 500. When selected, aStart Ad-Hoc Video window 504 may open, which may optionally requireentering a user or invitee' s contact information, such as telephonenumber and/or email address. Once invitee contact information isprovided, a unique and secure video link 506 may be sent to the inviteeusing the contact information, such as by SMS text message, email, orother forms of communication, as would be understood by a person havingordinary skill in the art. The link may also optionally be sent to aprovider. Once a notification or video link has been sent, the providermay be automatically directed to a virtual waiting room. Once a user,invitee, or patient engages the notification and/or link, they may alsobe directed to the virtual waiting room, which may initiate the videoconference once the parties have joined. According to some exemplaryembodiments, the video session facilitated through the virtual waitingroom may be initiated immediately, upon at least two parties joining, oronce all parties have joined. To conclude or complete a session, a “hangup” or end-session button may be provided. As shown in the figures, the“hang up” button may be a button at the bottom of a virtual waiting roomscreen and may optionally be red. Upon ending a session, the providermay exit the virtual waiting room and may be automatically returned to adashboard.

According to another exemplary embodiment, shown in FIG. 6A-6C, aninstant virtual exam room may be provided. Instant virtual exam roomembodiments may be beneficial to organizations that use electronichealth records as a master schedule. Instant virtual exam roomembodiments may have advantages of reducing the burden of addingpatients/users and virtual appointments to the system. Instant virtualexam room may also facilitate ensuring patients/users electronicallysign legal agreements or review documentation before receiving services.Appointment records may also be created in the system, which may alloworganizations to accurately track video metrics using a system reportfeature. An invitation for an instant virtual exam room visit may besent to a mobile phone number or email address, which may be entered ina start window, similar to the initiation of an ad-hoc appointment.According to some further exemplary embodiments, a user or invitee maybe selected from a stored list. Contact information associated with thatuser may be stored on a server and may be automatically used tocommunicate an instant virtual exam room invitation. When selected froma list, the invitation may be sent to one or more of an e-mail, a mobilenumber, or to a mobile device through a web or mobile applicationnotification. Instant virtual exam room appointments may be set up forimmediate connection or for a future time and may optionally be onlyavailable for video connection. The scheduler or provider may create ageneric appointment on a dashboard and may join the visit from thedashboard.

A provider may invite a user/patient to a instant virtual exam room bylogging in to the system. This may be done by navigating to and loggingin to a webpage or opening a mobile application to access a dashboard600. The provider may select to start an instant virtual exam room visitusing a button 602 on a common actions menu of the dashboard, as shownin FIG. 6A. An instant virtual exam room window 604 may open, which maybe shown in FIG. 6B. The instant virtual exam room appointment windowmay optionally include a provider field. This field may match adashboard's displayed provider if the system is only displaying and/orthe scheduler is only viewing one provider's appointments. The windowmay also show a start date and start time. The fields may auto-populateto a time within five minutes of scheduling. A duration may also beprovided and may optionally default to 15 minutes. The durationselection may be set for scheduling purposes and may optionally notaffect the actual duration of an appointment. The provider/scheduler mayenter a user/patient name, email, or phone number in a search bar, whichmay show possible users/patients for selection to book an appointment.The patient/user and/or the provider may receive a secure link 606 toaccess the video visit. It may be possible for new users to set up anaccount upon receipt of an invitation from a provider. It may also bepossible to disable self-signup and to instead allow an inviteduser/patient without an account to enter the appointment as an anonymoususer. Anonymous user set-up may also bypass any consent documents. Oncea provider sends an invitation, the invitation window may be closed andthe system may be directed to the dashboard, where the appointment maybe shown under an upcoming appointments section. When a user or patientjoins a video conference, an indicator may be shown to the provider. Forexample, the upcoming appointment may turn green to signify that theinvitee/user/patient has joined. The provider may begin the conferenceby selecting a start visit button. Upon completion, a hang up button maybe used to exit the conference and return to a dashboard view.

According to an exemplary embodiment, a patient, user, or invitee and/ora provider may receive a secure video link upon creation of anappointment by a provider, scheduler, or the user/patient. Furthermore,a patient or user may receive reminders regarding an appointment, whenapplicable. A patient/user may be required to verify identify with adate of birth or may be required to create an account. The identityverification or account creation may optionally be required to join avisit or to create/schedule an appointment. According to someembodiments, user account creation may be disabled by request.Furthermore, a patient/user may be able to view and sign electronicconsents or other forms when an appointment is scheduled or prior tojoining a visit. Instant virtual exam room scheduling may also allow fortracking of video session metrics by an organization.

According to still further exemplary embodiments, a single-page bookingembodiment of a video appointment scheduling system may be provided. Asingle-page booking embodiment may be beneficial for organizations thatuse electronic health records as a master schedule and for providersthat prefer using a dashboard in “calendar view.” In single-pagebooking, an invitation may be sent through a web or mobile applicationand may be sent by selecting a user/patient from a database of storedusers. Single-page booking may allow for setting up appointments for animmediate or imminent timeframe or may allow for scheduling appointmentsat a future time. Single-page booking may also allow for schedulingvideo connections, in-person appointments, or kiosk video appointments.According to an exemplary embodiment, a kiosk video appointment may befor an in-office video appointment or for a video connection through akiosk supported by the provider. This may allow for a user/patient to bein-office and conference with a provider that is out of office or in adifferent room. A kiosk visit may be helpful in minimizing oreliminating extended periods of in-person contact, which may minimize orprevent the spread of infectious diseases. A provider and user mayoptionally conduct all or some of an appointment using a kiosk. Aportion of the appointment may also be in-person. The ability to performparts of an appointment by video conference and only interact in-personfor necessary portions of the appointment is beneficial for socialdistancing practices during times of need, such as pandemics. Forimplementation, a scheduler and/or provider may create an appointment ona dashboard in a calendar view. The single-page booking may allow forselecting from a number of providers, locations, and/or appointmenttypes. The provider may also join the visit from the dashboard. Auser/patient may receive appointment reminders, connection tests, and/ora secure video link through single-page booking systems. Theuser/patient may also verify identity with date of birth and mayoptionally sign electronic consents and/or complete intake forms, whenapplicable. An organization may track detailed video metrics.

Single-page appointment scheduling may include a shortcut for staff orproviders to book an appointment with a single click in a dashboardcalendar view, which may allow for bypassing the appointment typeselection triage. Single-page scheduling may not be available for allorganizations and may be beneficial for practices with limited types andminimal provider filtering in the scheduling process. Single-pagescheduling may bypass all filtering options in the booking process andmay instead allow selection of any provider for any appointment type orlocation. As shown in FIG. 7A-7F, an exemplary embodiment of asingle-page scheduling system may be provided. To use single-pagescheduling, a dashboard 700 may need to be in a Calendar View, which maybe toggled with a List View/Calendar View button 702. The dashboard mayalso display a panel of calendar options 704 listing providers, visittypes, and locations within an organization. To schedule an appointment,at least a provider must be selected. According to other embodiments, aprovider and a visit type must be selected or identified. For in-personor office video/kiosk appointments, a location must also be selected. Atime slot length, month, week, and/or day may be toggled for anappointment being scheduled using a date and time interface 706. Oncethe appointment details have been established, an open/available spaceon the calendar may be selected to create a new appointment slot. Theslot can be dragged to modify or may be canceled by pressing an X orclose button and to book the appointment, a check mark may be selected.When booking the appointment in a Book an Appointment window 708, a newpatient may be added by selecting a plus sign instead of entering a namein the search bar or the search bar may be used to locate and select auser or patient existing in the system. The appointment type, location(if applicable), provider, and time slot may be pre-populated based onoptions chosen prior to clicking the desired slot; however, these fieldsmay be changed through the Book an Appointment window. If all items areas desired, the scheduler/provider may select “Next,” which may presenta confirmation screen and the ability to “Book” and schedule theappointment.

Now referring to exemplary FIG. 8A-8I, there may also be a fullappointment scheduling system and interface 800. A full appointmentscheduling process may be beneficial for organizations that use thepresent system as a master schedule, organizations that havemulti-specialty practices, organizations that have multi-locationpractices, and/or organizations that allow patient self-scheduling.According to an exemplary embodiment, invitations may be created andsent to a user/patient through the system and may utilize stored orentered contact information and/or notification through a web and/orsoftware application. Full appointment scheduling systems may providefor booking of appointments for immediate conferencing or meeting at afuture time. Furthermore, full appointment scheduling systems may set upappointments for video connections, in-person appointments, and/oroffice video/kiosk appointments. The scheduler and/or provider mayutilize an appointment selection triage to ensure a correct provider,location, and appointment type are selected. The scheduler and/orprovider may further join the visit from the dashboard. The patient maybe able to receive appointment reminders, connection tests, and/or asecure video link. The patient may further optionally be able to verifyidentity using a date of birth and may sign electronic consents and/orcomplete intake forms when applicable. The providing organization may beable to track detailed metrics of appointments and video conferencing.

According to some exemplary embodiments, a payment may be sought by ascheduler/provider during the booking process. Scheduling a newappointment may be initiated by a scheduler or provider by selecting abutton on a dashboard or by selecting a “plus” sign next to anappointments tab of the menu tab. The first step to schedule anappointment may be to select a patient, which may be done by locating anexisting patient in a records database or by selecting to add a newpatient to add a new patient to the patient list. Once a patient hasbeen located or added, they may be selected for the appointment. Thescheduler may then select whether the appointment is for an adultpatient by selecting “Self” or “Dependent(s)” for appointments for aminor or individual under someone else's care. If Dependent(s) isselected, additional information may be required, such as selection of astored list of individuals associated with the account including aparent or guardian and any associated dependents.

Next, an appointment selection triage page of the system may beprovided. The triage page may be customizable based on organizationprotocols and may be intended to help guide schedulers and providers toensure appropriate appointment types are selected for a user/patient.The triage page may present a number of questions to guide thescheduling process. For example, the triage questions may focus on thepatient type (new or established, adult or pediatric, insurance or selfpay, etc.) or the provider type they are seeking (specialist, medicaldoctor, therapist, etc.). The triage system ay also ask to verify apatient's complaints are appropriate for the appointment type. Accordingto organizational determination, various appointment types may beprovided. For example, video appointments may be provided where patientsand providers connect face-to-face from different remote locations usingtheir own devices, office video appointments may be provided wherepatients present to an office location and use a kiosk device to connectface-to-face with a provider in a remote location or another area of theoffice location, in-person appointments where a patient presents to aphysical location and meets with a provider in that location, andmessaging appointments where a patient and provider communicateasynchronously in a messaging chain. If scheduling an office video orin-person visit, a scheduler may be prompted to select a location as anadditional step. Furthermore, a list of providers available for anappointment may be filtered based on the appointment type selected,provider credentials or specialty, age of the patient, and/or thelocation(s) where the provider is available. Likewise, a list ofappointment types available under a provider may be filtered based onthe provider. A selection of open slots, if any, may be shown next toeach respective provider. For example, the next three open slots may beshown and a “more” option for viewing additional slots may be provided.The “more” selection may reveal a full calendar screen, which may allowfor selecting an appointment date and time by clicking an open space.When an open space is clicked, a green “New Appointment” icon mayappear, which may be clicked and dragged to a desired slot on thescreen. When in a desired place, a “Set Selected Date” option may beentered. The calendar may include a mobile-friendly version. The fullcalendar may optionally have arrows for navigation and/or a “Select Day”entry for jumping to a desired date. A time may be selected using a“Select” button. A payment method may also be selected for booking.Lastly, the appointment details may be confirmed by scrolling throughthe page-by-page information. Once checked, the appointment may bescheduling by selecting “Book” or “Charge” if a payment step isrequired. Once booked, the appointment may be added to the provider'supcoming appointments and a first patient or user notification may besent by at least one of email and text message.

Referring to FIG. 9A-9B, and according to still further exemplaryembodiments, a group appointment scheduling process, system andinterface 900 may be provided. Group appointments may allow for invitingmultiple users to a single appointment, whether in-person or on a securevideo connection. Group appointments may be scheduled on a one-time orrecurring basis. To begin setting up a group appointment, a group mustbe stablished. Using an add group selection, the system may collectinformation including some or all of a group name and description. Thename may be visible to the users and/or patients in the group, but thedescription may optionally only be visible to providers, staff, and theprovider organization. The group may then be completed by selectingusers from the stored database or optionally by adding new userinformation. Once a group has been saved, a number of actions may beprovided, including scheduling a single appointment for the group,setting a regularly recurring appointment schedule for the group,assigning a form or assessment to all group members, viewing the detailsof the group that has been created, inviting new patients, staff, orproviders to the appointment or removing existing users using an editfunction, or clearing the group form the available group appointmentsthat may be booked using a delete function. According to a single groupappointment process, the booking process may be triggered from an“Actions” menu on a groups page or a button on the dashboard. The singlegroup appointment booking process may be similar to that for anindividual appointment. Each individual in a group may receive at leastone of text or email reminders with instructions and a unique securelink to connect. For recurring schedule appointments, a regularlyrecurring schedule for the group may be facilitated. If a GroupScheduling Enabled selection is turned on, appointments may be bookedautomatically according to a set frequency. When saved, all members of agroup may be notified that they have been scheduled for a recurringgroup appointment. Furthermore, each individual may receive reminderswith instructions and a unique secure link. According to someembodiments, a reminder and link may be provided 24 hours prior to eachsession and again 30 minutes before each session. For a provider to joina group video appointment, the appointment may be selected from theircalendar or, if initiated by another provider or staff, the appointmentmay be accessed by following a link in a provided notification orreminder regarding scheduling of the appointment.

Now referring to exemplary FIG. 10A-10D, a book again process, system,and interface 1000 may be provided. According to the book again feature,a shortcut may be provided to schedule another appointment for the samepatient with the same provider. This option may typically be used toschedule follow-up appointments. When a provider selects to book again,a prompt may ask whether the provider is scheduling the appointment orwhether the provider is allowing the patient to schedule 1010. If theprovider selects to schedule themselves, the provider's calendar may beshown 1020. An available time may then be selected to schedule theappointment and, if applicable, the appointment type may be added. Ifthe organizational preferences allow the system to support Recalls, theprovider may choose between scheduling the appointment now or sendingthe patient a reminder to book on a future date 1030. In Recallsembodiments, after selecting book again and selecting to let the patientschedule, a future date may be selected for an appointment schedulingreminder to be sent to a patient. The Recall may then be scheduled andthe date confirmed.

Now referring to exemplary FIG. 11A-11F, unapproved appointments andpending requests processes, systems, and interfaces 1100 may beprovided. Unapproved appointments and pending requests sections may beavailable through a dashboard, if permitted by an organization.Unapproved appointments may be available where an organization allowspatient self-scheduling, but requires a provider or staff member toapprove self-scheduled appointments and where an organization allowspatient self-scheduling but does not require provider or staff approval,but instead all appointments scheduled by patients are routed directlyas upcoming appointments. If a patient requests to cancel or reschedulean appointment, it may be shown in a pending requests section. When apatient self-schedules an appointment, a notification may be providedthat the appointment is pending approval. An associated provider mayalso receive a notification prompting them to select at least one ofapprove, modify, or deny the appointment. In addition to approve andmodify selections, a details selection may display patient andappointment information, a book again selection may provide a shortcutto schedule a follow-up appointment of the same type for the patient, acancel selection may cancel the appointment and remove it from thedashboard, and an assessment selection may provide a shortcut to send aform to the patient. Selecting approve may prompt the appointment tomove from an unapproved appointments list to an upcoming appointmentslist. The upcoming appointments list on the dashboard may showappointments for a predetermined upcoming range and a full upcomingappointments list may be provided on a more detailed appointments page.Selecting approve may also send a notification to the patient to confirmthe appointment has been scheduled and presenting all instructionsnecessary to connect. Selecting modify may present a modify appointmentwindow, which may show patient information and may allow for editing ofappointment type, provider, location (if applicable), date and time,check in, and symptoms. Upon saving modifications, the appointment mayautomatically be approved. According to a pending requests section, ifan organization allows patients to reschedule or cancel appointments,patients may do so from a secure link in their notifications or bylogging in to their account. All requests to cancel or rescheduleappointments may optionally appear under a pending requests section on adashboard. A provider may view the appointment requests, includingpending cancellations or pending reschedule requests. According to someexemplary embodiments, an organization may request a patient reason,which may be displayed with the pending request. A provider may thenapprove or deny the request from the pending requests section.

According to an exemplary embodiment, a virtual waiting room may beprovided. The virtual waiting room may present a blank screen or mayoptionally present a screen showing instructions to remain connectedawaiting the other participant(s). A virtual waiting room may be enteredwhen accessing a scheduled appointment and awaiting other participantsor when a user schedules to be seen immediately. According to someembodiment, a virtual waiting room may be presented until a providerselects to start an appointment and/or when a provider or user leaves anappointment or temporarily puts an appointment on hold. Controls forin-meeting actions and preferences may optionally be available whilewaiting. Furthermore, consents, documents for electronic signature orother informational documents may be accessed and/or completed by aprovider, patient, or user in the virtual waiting room. According tosome embodiments, a small window or picture-in-picture within thevirtual waiting room may show the view through the respective user'scamera displayed to the other meeting participant(s).

Now referring to exemplary FIG. 12 , a patient/end user appointmentscheduling process and interface 1200 may be described. An organizationmay allow patients to do some or all of self-schedule, re-schedule,confirm, and/or cancel an appointment. A user may create an accountand/or login to a system account through a webpage portal or softwareapplication. The user may then be presented with a dashboard, which mayprovide at least one of tasks, action items, preferences, and personalinformation. Through a user dashboard, a user may access forms anddownloadable information. Furthermore, a user may select to schedule anappointment. When booking an appointment, a select patient option may bepresented. Patients may be able to book appointments for themselves orfor any applicable dependents. If selecting a dependent, an additionalscreen may be presented to specify the dependent. Patient informationmay be entered and stored with an account prior to booking anappointment. Once a patient has been selected, a reason for a visit maybe entered. According to organizational preferences, a reason may beselected from a pre-set list, entered in free-form text, or skippable. Avisit type may also be entered. When entering a visit type, the systemmay collect some or all of the following information: where the patientis located, whether it is a new patient, whether symptoms are listed ona preset list, how the appointment will be paid for, and if a specialistis needed, such as therapy, medication management, dermatology,podiatry, and other specialists as would be understood in the art. Thesystem may also seek information on whether the patient/user would liketo book a future appointment or be seen immediately. For immediateappointments, it may be possible to immediately reroute a patient to avirtual waiting room. A patient/user may select a provider from a list,which may be filtered based on a number of factors, such as type of careand availability. Once filtered, any provider available may be selectedfor an appointment. Open time slots shown may be selected or an optionmay be selected to see more options, which may present a scrollable listview and/or a calendar view. Organizational preferences may also requestpayment information to pay a co-pay or full self-payment. Once a patiententers payment information, it may be charged immediately and stored ordeleted, or may be stored for payment at a later date and/or futureappointments, depending on organizational preferences. The system maypresent appointment information to review and confirm. Once approved and“booked” by the patient, organizational preferences may require approvalfrom a provider or may allow the appointment to be booked if no approvalis required. A patient or user may receive an appointment confirmationshowing one or more of the following: appointment date and time, aprovider's name, a link to confirm the appointment, a link to cancel orreschedule (if applicable), a location and directions (if applicable),and for video appointments, a link to test a browser, camera,microphone, speaker, and internet connection, a secure link to connectto the appointment, and a unique code to connect to the appointmentand/or a unique code to connect to the appointment on a mobile device(when applicable).

Once booked, an end user or patient may be able to reschedule and/orcancel an appointment according to organizational preferences. Toreschedule, a user may select a reschedule option from a user dashboardor appointments page. A unique link to reschedule and/or cancel anappointment may also be sent to a user in an appointment notification,such as a confirmation or reminder e-mail or text message. A user may berequired to verify identity by entering a date of birth before beingauthorized to reschedule or cancel an appointment. When rescheduling,additional timeslots may be presented to the user. Alternative timeslots may be selected on the same day or additional days. For canceling,a cancel option may be provided. According to organizationalpreferences, a reason may be required for rescheduling and/or canceling.Once an appointment is rescheduled or canceled from a patient, it may beautomatically approved or in some embodiments it may be pending approvalfrom a provider. The provider may be alerted to the requested change andmay approve, deny, or modify the reschedule or cancelation.

The above descriptions may list certain features associated withdifferent scheduling system options; however, it may be understood thateach of the above-described features may be used in any combination forvarious embodiments of the system.

Now referring to exemplary FIGS. 13 and 14 , a predictive schedulingapplication for identifying appointment cancellations, no-shows, andhigh-risk appointments may be provided. A high-risk appointment may becategorized based on an assigned probability of cancellation or no-show.There may be a customizable threshold probability for consideration as ahigh-risk appointment. For example, one embodiment may associate ahigh-risk label to any appointment in which the high-risk probability isabove a certain number, e.g. 40 on a scale from 0-100, while others mayutilize a different threshold number. Additionally, in cases in which anorganization's appointment outcome history does not cleanly map to a0-100 risk scale (for example, in the case that averaged appointmentdata reports a significant risk for many appointments but that risk isnot reflected in reality), the risk score may be normalized to adifferent scale, e.g. between 20 and 100, between 0 and 80, etc. Thismay allow for the predictive scheduling application to communicatescores that are clearly understandable to a user. The predictivescheduling application may use machine learning and or artificialintelligence (AI) to obtain and analyze factors, which may be applied toa predictive model for determining appointment cancellations andno-shows. The exchange of any patient information and appointment datamay be made in a safe, secure and HIPAA compliant manner. Factors usedby the predictive scheduling application may include, for example,demographic data, appointment data, patient scheduling data, and/orpatient form data. Additional data factors for training models andgenerating predictions may include, but not be limited to, time betweenappointment scheduling and actual appointment date (in other words, howfar in advance an appointment was made), which may be measured in anydesired increments including days or months; date and time of anappointment, appointment type (video, office, or kiosk); patient and/orguardian, if applicable, confirmation status for the appointment; priorlogin of patient and/or guardian, if applicable; completion ofappointment connection test; past history of high-risk outcomes ofpatient, such as prior cancellations or no-shows; basic patientdemographics, such as age, gender, presence of valid contactinformation; past history of high-risk outcomes of provider, such asprior cancellations or no-shows; basic provider demographic, such as ageand gender; provider specialty; and appointment density of both patientand provider, including how many appointments in a given time period.This non-exclusive list of factors may be applied to a scoring algorithmor otherwise correlated to a risk probability scale, as would beunderstood by a person having ordinary skill in the art.

Referring to exemplary FIG. 13 , a diagram showing a system architectureand an overall flow of actions and data for the prediction system may beprovided. A user interface or website 1302 may be provided, which mayshow a likelihood of appointment attendance and which may allow for ondemand attendance prediction requests. According to some exemplaryembodiments, this may be a unique interface from a patient interface forscheduling and/or requesting an appointment and may instead by aprovider interface which may optionally be accessible only by a provideror scheduler. The interface 1302 may receive prediction data for eachappointment from an Application Programming Interface (API) 1304 and maycommunicate prediction requests to the API 1304. A software scheduler1306 may also communicate appointment data to the API 1304 to requestpredictions for approaching appointments on a daily basis. The API 1304may manage prediction requests for new appointments, updatedappointments, and approaching appointments. The API 1304 may communicatewith a database 1308. Specifically, the API 1304 may communicateappointment requests to the database 1308 and may receive appointmentprediction data from the database 1308. The database 1308 may be acloud-based database. The database 1308 may be used to create a databaseread replica 1310, which may include appointment prediction request dataand appointment and user data. The requests and appointment and userdata may be read or processed by a prediction service 1312. The systemmay employ a microservices architecture and the prediction service maybe a microservice. The prediction service 1312 may read enqueuedrequests for predictions from the database read replica 1310 and maysend requests containing formatted instance data to an AI platform 1314.The prediction service 1312 may also save prediction records from the AIplatform 1314 to the database 1308 and may mark requests as complete inthe database 1308. The AI platform may include one or more servedmodels. Models may be trained and uploaded manually. According to somefurther exemplary embodiments, a pipeline may automatically train newmodels and serve them. The AI platform 1314 may communicate predictionsto the prediction service microservice 1312, which may save predictionsto database 1308 and mark requests as complete in database 1308, asdetailed above. The predictions may then be communicated to and/oraccessed by the API and may then be displayed through interface 1302.

According to an exemplary embodiment, the predictive schedulingapplication or prediction platform and system may utilize severalstages, each employing state-of-the-art processes and leveraging thelatest capabilities of machine learning. To ensure optimal accuracy andbolster the strength of predictions made by the prediction platform, theplatform may combine multiple types of inference engines or machinelearning modules.

The platform may include a modular structure, which may employ multiplestages that can each be independently tweaked by changing values in arespective section of a configuration file or files. To initiate theprediction platform, a provider or user may trigger a request togenerate a prediction regarding the probability of a high-risk outcomefor an appointment through either a creation or update action and/or aninternal server may trigger a daily calculation of upcomingappointments. Other possible triggers for initiating the predictionplatform may be understood by a person having ordinary skill in the art.According to still further exemplary embodiments, a prediction platformmay run periodically and/or continuously to automatically auditscheduled appointments and to provide updated appointment status and/orclassification based on the prediction outcomes. The system may have anappointment data store and may also create and utilize read replica ofthe appointment data store. An application programming interface (API)may make a query to a read replica of the appointment datastore. Thismay ensure client data is protected and that patient care cannot beinterrupted through database operations on a main datastore. In additionto preventing corruption of a main data store, preventing interruptionof patient care, and ensuring data protection and privacy, creating andutilizing a read replica of the appointment data store may improvecomputing performance for the prediction process and for actionsinvolving the main data store by reducing respective traffic andrequests on each resource. The data stores may be cloud based or may bestored on one or more local servers. The read replica may reflectchanges to the primary or main appointment data store in real-time ornear real-time, as would be understood by a person having ordinary skillin the art. A scheduling system may retrieve relevant appointment dataand send a request to the prediction system.

Referring to exemplary FIG. 14 , a diagram detailing a machine learningcomponent of the prediction system may be provided. Upon receiving aprediction request, the appointment data 1402 may be formatted into astandard format and then may be passed to a prediction pipeline. In theprediction pipeline, the first stage may be a data pre-processor 1404.The data pre-processor may be a sub-pipeline, which may stripsuperfluous descriptors, drop unnecessary columns, encode certaintime-cycle features, impute missing values for each feature, and thenindependently encode each feature, if necessary. The data pre-processormay yield cleaned and normalized data 1406.

According to an exemplary embodiment, the data pre-processor may stripsuperfluous strings. At this stage, data type labels from internal datamay be stripped out. Since the appointment scheduling and remoteconferencing platform may interact with data using a variety oftechnologies, strings may be appended to labels in a database so thatengineers and users may easily determine how to work with the data.While the added strings may provide efficiencies when working with thedata, these added strings are not necessary for the prediction system.By removing these added strings, the system may be optimized. This mayimprove computing performance.

Furthermore, the data pre-processor may drop any unnecessary columns orfeatures. These features may be defined by a user prior to runtime usinga configuration file. Dropping unnecessary features may reduce themagnitude of features that are to be processed, improving performance,and can also be leveraged to protect privacy of users by removingsensitive features, if such sensitive features were ever present. Thepre-processor stage may be leveraged in the prediction system to ensurethat predictions do not suffer from a phenomenon known as overfitting.Overfitting may refer to a trend in a predictive model in which themodel's learned representation of the data is too specific to trainingdata, which may lead to poor predictions. This is a critical flaw toavoid in machine learning platforms. In order for models to generalizeacross features, all features must have some sort of constraint on theirrespective set of possible values, such that same-feature commonalityexists between instances. In other words, the model must not use anyfeatures for which the values cannot possibly be the same between twoappointments.

Next in the pre-processor stage, the system may utilize a cyclicalencoder to process certain data. Models may try to learn therepresentation of features, whether they may be continuous on a rangefrom one number to another or discrete between different categories. Forexample, in many databases and computer systems, dates may berepresented in human-readable formats, such as January: 1, February: 2,etc. However, machine learning models may interpret these “time-cycle”values as having a larger magnitude or importance, when they are, infact, of the same importance. In order to prevent inaccuraterepresentations from being learned by the base models, this equality maybe instilled in the machine learning models. This may be accomplished byprojecting the date values onto a unit circle, which may allow theirmagnitudes to remain the same while giving each possible value adifferent position in a project space. This may force the models tolearn that all values in such special features are equally valid andhave a relation to one another.

Additionally, classifiers may not be capable of dealing with missingvalues, which may require an imputation stage for accurate modeling.Therefore, all missing values may be corrected at the pre-processorstage. For example, some data types may be collected by a systemprovider for appointment requests, which may not be collected by aclient organization. This may lead to instances in which an appointmentrequest may have missing data. While other stages may remove suchfeatures, it is possible that some instances may remain. Therefore, allempty cells must be accounted for and filled. The system may utilizedifferent strategies to fill empty cells, depending on the type offeature in which it occurs. According to an exemplary embodiment, thesystem may fill cells according to a predetermined number or string,which may be assigned to the empty cell.

Lastly, the pre-processor stage may perform label encoding, which maytranslate human-readable string values into a format that can beunderstood by the machine learning models, which may not understandhuman-readable string values. In this step, which may optionally be alast step of the pre-processing pipeline, each categorical feature maybe label encoded, whereby each of the discrete values in that featuremay be replaced with an integer value that may correspond to thatfeature. Therefore, any string that may be supplied by an organizationfor a certain feature may be mapped to an understandable format for thepredictive models. The label encoding stage may also mitigate otherharmful phenomenon in machine learning, such as data leakage. Dataleakage is an event in which data that would not be available atprediction time is included in a model's learned representation afterundergoing training. Since models leverage all data available duringtraining in order to increase accuracy, the presence of data duringtraining that will not be available when making actual predictions mayresult in reduced prediction accuracy or completely wrong predictions.

Once the pre-processor stage is complete, the resultant data may begiven to a base classifier group. According to an exemplary embodiment,this may include a random forest ensemble, gradient boosted machinemodel, and neural network. Predictions for each model type in the groupmay then be analyzed by a group of false negative classifiers. If, andonly if, a false negative is detected for an appointment, then theprediction for that particular appointment may be adjusted. Resultantprobabilities may then subsequently be collated and sent to a finalstage, which may be a meta-classification model. The system may generatea final risk score using predictions from the base models. Ahuman-readable confidence string may be assigned depending on themagnitude of a risk score. The metrics may be paired together for eachappointment instance that the prediction system was tasked withpredicting and all instances may be collected into an easilycommunicable payload. The payload may then be returned by the predictionsystem to the API, which may then send changes to a front-end. Providersmay be able to see the probability of a high-risk outcome, which mayallow them to make more informed decisions about a patient'sappointment.

According to an exemplary embodiment and as summarized above, afterappointment data is pre-processed, it may be passed to theclassification stage. The prediction may employ three separate modeltypes in an ensemble: a random forest classifier 1408, a gradientboosted machine classifier 1410, and a neural network classifier 1412.The classification stage may be completely modular, which may allow forthe possibility of replacing a model type or further strengthening thenetwork through addition of a more accurate model type. In someembodiments, each model type used may be industry-trusted; however, theoverall structure of the present system may differ by leveraging a modelof each type to capture the advantages and mitigate the disadvantages ofthe respective model types through unique customizations. According somealternative embodiments the classification stage may employ less modeltypes, as would be understood by a person having ordinary skill in theart.

All models may be encapsulated in a standard interface in order tooptimize the throughput of the prediction system. Pre-processedappointment data, or cleaned and normalized data 1406, may be passed toeach of the models and base predictions, or prediction probabilities1414 may be generated from this data. The base predictions may then beanalyzed by another set of classifiers that may be trained to detectfalse negatives, a false negative classifier 1416. According to anexemplary embodiment, false negatives may be predictions indicating thatan appointment will not result in a high-risk outcome, but theappointment does, in fact, result in a no show or cancellation. Reducingfalse negatives, such as this, are important for successfully optimizingthe system. Therefore, a negative classifier is associated with eachmodel type. If a false negative occurrence is detected, the originalbase prediction may be adjusted to reflect the uncertainty, yieldingadjusted prediction probabilities 1418. After a false negative detectionstage, all appointment predictions, which may be adjusted predictionprobabilities 1418, may be passed onto a meta-classification stage. Atthe meta-classification stage, each appointment may have its basepredictions from each model type associated together and ameta-classifier 1420 may make a final prediction 1422 or yield finalattendance probabilities 1422. According to some exemplary embodiments,the meta-classifier may be a neural network type classifier 1420.

The above described classifier arrangement may enable using moreinformation for predicting an outcome while also keeping computationalrequirements to an optimally small and fast level. The describedclassifier arrangement enables more information through the diversityand variety of its constituent approaches. Each of the classifier typesalso gives metadata that, while not necessarily in-use at a particularmoment in time, may give additional insight into respective predictionsof the classifier. For example, one type of classifier may giveinformation about feature importance, which may facilitate makinginformed decisions on whether to include a feature (creating a leanermodel as there are fewer calculations to make) or increase the weight ofsaid feature (potentially leading to more accurate predictions). Eachclassifier type has metadata that can be used to improve those twogoals: a smaller/faster model, and a more accurate model. In embodimentsusing multiple types of classifiers, leveraging other types of metadatathat could aid in further refinement of models may be made possible,which may improve performance.

According to some exemplary embodiments, the classification may bestructured such that each model type is provided with differentappointment data, which may or may not overlap, to optimize theeffectiveness of respective models or the combination of models.Alternatively, each model type may be provided with identicalappointment data, as would be understood by a person having ordinaryskill in the art.

The foregoing description and accompanying figures illustrate theprinciples, preferred embodiments and modes of operation of theinvention. However, the invention should not be construed as beinglimited to the particular embodiments discussed above. Additionalvariations of the embodiments discussed above will be appreciated bythose skilled in the art (for example, features associated with certainconfigurations of the invention may instead be associated with any otherconfigurations of the invention, as desired).

Therefore, the above-described embodiments should be regarded asillustrative rather than restrictive. Accordingly, it should beappreciated that variations to those embodiments can be made by thoseskilled in the art without departing from the scope of the invention asdefined by the following claims.

What is claimed is:
 1. A method for providing an efficient and secureinterface for transferring electronic information, comprising:transmitting a unique access link to a user device or kiosk, the uniqueaccess link being directed to the transfer page; requiring entry of apersonal identifier when the unique access link is accessed; verifyingthe personal identifier by comparing the personal identifier with apreviously stored set of personally identifiable information; when thepersonal identifier is verified, granting the user device or kioskaccess to transfer electronic information; and wherein the transfer pageis a no-login page using identity verification for access.
 2. The methodof claim 1, wherein the transfer of electronic information comprises atleast one of uploading or downloading files, entering or reading text,submitting intake forms, and connecting to live video or audioconferencing.
 3. The method of claim 1, wherein the unique access linkis sent by one or more of email, SMS, or push notification.
 4. Themethod of claim 1, wherein identity verification requires data capturedin real-time by a user device or kiosk.
 5. The method of claim 1,wherein the personal identifier is collected during account creation. 6.The method of claim 1, wherein the personal identifier is a date ofbirth.
 7. The method of claim 1, wherein the transfer page supports atleast one of uploading of electronic information, submission of intakeforms, and live video or audio conferencing.
 8. A system for providingan efficient and secure interface for transferring electronicinformation, the system comprising a server device and a networkconnection, the server device being configured to execute stepscomprising: transmitting a unique access link to a user device or kiosk,the unique access link being directed to the transfer page; requiringentry of a personal identifier when the unique access link is accessed;verifying the personal identifier by comparing the personal identifierwith a previously stored set of personally identifiable information;when the personal identifier is verified, granting the user device orkiosk access to transfer electronic information; and wherein thetransfer page is a no-login page using identity verification for access.9. The system of claim 8, wherein the transfer of electronic informationcomprises at least one of uploading files, downloading files, enteringor reading text, submitting intake forms, and connecting to live videoor audio conferencing.
 10. The method of claim 8, wherein the uniqueaccess link is sent by one or more of email, SMS, or push notification.11. The system of claim 8, wherein identity verification requires datacaptured in real-time by a user device or kiosk.
 12. The system of claim8, wherein the personal identifier is collected during account creation.13. The system of claim 8, wherein the personal identifier is a date ofbirth.
 14. The system of claim 8, wherein the transfer page supports atleast one of uploading electronic information, submission of intakeforms, and live video or audio conferencing.
 15. A non-transitorycomputer readable medium having stored thereon software instructionsthat, when executed by a processor, cause the processor to: open aunique access link directed to a page, wherein the page supports atleast one of transfer of electronic information, submission of intakeforms, and live video or audio conferencing; request access to the pageusing a personal identifier; upon verification of the personalidentifier, access the page; wherein the page is a no-login page usingidentity verification for access.
 16. The non-transitory computerreadable medium of claim 15, wherein the unique access link expiresafter a predetermined time interval or after being followed apredetermined number of times.
 17. The non-transitory computer readablemedium of claim 15, further comprising capturing real time data using acamera, audio recording device, or graphical user interface for identityverification and sending the real time data to a server forverification.
 18. The non-transitory computer readable medium of claim15, wherein the personal identifier is collected during accountcreation.
 19. The non-transitory computer readable medium of claim 15,wherein the personal identifier is a date of birth.
 20. Thenon-transitory computer readable medium of claim 18, wherein the uniqueaccess link is received by one or more of email, SMS, or pushnotification.